System and method for zero-footprint screen capture

ABSTRACT

A system for zero-footprint screen capture, comprising a communication server software module, a screen capture server software module, a web server software module, and a media upload server software module, wherein the web server, on receiving a request for a specific web page from a client application whose screen is to be captured, uploads a persistent screen capture software application to the client, and further wherein, upon receiving a connection request from the screen capture application, establishes a persistent connection to the screen capture application and, on receiving a notification from the communication server pertaining to an interaction involving a user of the client application, sends instructions via the persistent connection to the screen capture application, and wherein the media upload server receives via the established connection to the uploaded screen capture application one or more data packets containing screen capture graphics data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/359,484, titled “SYSTEM AND METHOD FOR ZERO-FOOTPRINT SCREENCAPTURE”, filed on Jan. 26, 2012, the entire specification of which isincorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

Field of the Invention

The invention relates to the field of contact center software, and moreparticularly to the field of monitoring or recording contact centeragent performance using screen capture of an agent's actions taken on acomputer while handling customer interactions.

Discussion of the State of the Art

An important aspect to be considered in managing any contact center (orcall center, which is a contact center handling only phone calls) is totake steps to ensure that the quality of interactions with customers isas good as can reasonably be achieved. The measurement of quality,especially when considered as the measurement of quality as perceived bya customer, is a challenge of great difficulty. In order to facilitateboth measurement of service quality and to monitor performance ofcustomer service representatives (typically referred to as “agents”,which term will be used herein), it has become commonplace for some orall calls to be recorded in order that the calls can be listened to, atlater more convenient times and using various sampling techniques, byprofessionals referred to as “quality monitors”. Virtually all contactcenters of any size have a full-time staff of quality monitors.

In addition to listening to the audio content of a call, it isadvantageous to also be able to see what an agent was doing during thecall as well. For example, by seeing what an agent was typing as acaller recounted a particular problem which required service to resolve,a quality monitor might be able to identify a training issue (as when anagent is found to be so focused on typing word for word what a customeris saying that the agent misses the point the customer was trying tomake, or when an agent incorrectly classifies a call and thereaftersends it to an incorrectly chosen specialist). Because of the obviousutility of capturing both audio and screen capture records of whattranspired during a service incident (or call), the use of screencapture technologies has become a mainstream element of modern contactcenters.

Unfortunately, systems that capture screens of agent desktops duringcalls tend to be quite expensive, require dedicated technical staff tomaintain, and generally store their screen capture data locally (alongwith audio call recordings). These facts mean that screen capture isoften not carried out by smaller contact centers, which do not have thebudgets or the technical staff needed to implement, maintain, and usesuch systems. Additionally, many larger contact center operators havefound it difficult to maintain separate call monitoring databases ateach contact center site, and have moved toward centralizedadministration and storage of call monitoring records (by which is meantaudio and screen capture recordings). However, even for largeorganizations, maintaining centralized call recording systems has provenchallenging and expensive. In addition, for large corporations, the costand technical challenges of keeping large amounts of agent desktops upto date (since each of them generally has had to have a dedicated screencapture application running on it, which communicates with thecentralized recording storage systems) have proven to be significant.And finally, as contact center outsourcing (which primarily meansoutsourcing the work of contact center agents) has expanded worldwide, aproblem has emerged because it is difficult for a large enterprise tokeep multiple outsourcers up to date with their screen capturesolutions—and for outsourcers the problem is even worse, as theytypically have to build integrations and stay current with multipleclients' different approaches to call and screen recording.

At the same time as these problems have become pressing in traditional,premise-based contact center systems (that is, systems where thehardware and software used reside on the premise of the contact centeror in a nearby data center operated by the same company), cloudcomputing has emerged as a major new paradigm in business (and consumer)computing. In cloud computing, physical resources are located away fromusers, accessible via the Internet to users from many enterprises.Deploying software “in the cloud” holds great promise for enterprises,as it promises to provide ready to access to the latest, highly-testedversions of each application without the enterprise having to manage thesoftware maintenance process.

From the perspective of call and screen recording, cloud-based computingis perhaps even more promising. A single cloud-based vendor can easilybuild, integrate, and maintain a solid, well-tested platform for callrecording and screen capture, and can then make it accessible to manyclients (enterprises) with minimal setup times. Moreover, cloud-basedsolutions are typically paid for as they are used, so what was once asignificant capital expense that was hard to size (enterprises oftentend to buy more than they need for normal operations, since they planfor peak period usage) has become a highly-variable operating expense(surging for peak periods is usually quite simple, and the extracapacity is only paid for when used).

Given the challenges in screen capture solutions, that have limitedtheir use in small contact centers, in large, multisite operations, andin or in conjunction with outsourcers, a shift to cloud-based solutionsoffers very compelling advantages. However, existing efforts to deployscreen capture from the cloud have generally involved installation of aspecialized software application on the desktops whose screens are to berecorded, with the result that adoption of cloud-based screen capturesolutions has been limited to specialty applications to date, and hasnot been adopted much in the contact center world.

What is needed is a cloud-based screen capture solution suitable for usein call centers both large and small, and with or without outsourcing,that does not require any permanent software installation on agentdesktops.

SUMMARY OF THE INVENTION

In order to address the problems in the art described above, in apreferred embdodiment the inventor has conceived and reduced to practicea system for zero-footprint screen capture, comprising a communicationserver software module operating on a network-connected computer, ascreen capture server software module operating on a network-connectedcomputer, a web server software module operating on a network-connectedcomputer, and a media upload server software module operating on anetwork-connected computer. According to the embodiment, the web server,on receiving a request for a specific web page from a client applicationwhose screen is to be eligible to be captured, uploads a persistentscreen capture software application to the client; and upon receiving aconnection request from the screen capture application uploaded to theclient, the screen capture server establishes a persistent connection tothe uploaded screen capture application; and the screen capture server,on receiving a notification from the communication server pertaining toan interaction involving a user of the client application, sendsinstructions via the persistent connection to the uploaded screencapture application. Further, the media upload server, on receiving aconnection request from the uploaded screen capture application,establishes a connection to the uploaded screen capture application, andreceives via the established connection to the uploaded screen captureapplication one or more data packets containing screen capture graphicsdata.

According to another embodiment of the invention, the data packetscontaining screen capture graphics data are stored in a media storagedatabase connected to the media upload server. According to yet anotherembodiment of the invention, the data packets containing screen capturegraphics data are transmitted by the media upload server to a monitoringstation for viewing by a monitoring user. In a further embodiment, theuser of the client application eligible for screen capture is an agentof a contact center. In another embodiment, the data packets areformatted using a protocol that allows at least variable screen capturegraphics data compression based on available upload bandwidth. In someembodiments, a plurality of media upload servers are used, and thescreen capture server, when sending instructions to the screen captureapplication to commence a screen capture operation, includes in theinstructions an identity or a location of a particular media uploadserver to connect to for the screen capture operation being commenced.

In another preferred embodiment of the invention, a method forzero-footprint screen capture is disclosed, The method comprising thesteps of: (a) establishing a connection from a client desktop of acontact center agent to a web server; (b) uploading and installing ascreen capture application from the web server to the client desktop ofthe contact center agent, if a screen capture application is not alreadyinstalled on the client desktop; (c) establishing a connection from theuploaded screen capture application to a screen capture server; (d)receiving a notification from a communication server at the screencapture server pertaining to an interaction involving the contact centeragent; (e) based at least on notification received, sending instructionsfrom the screen capture server to the uploaded screen captureapplication instructing it to commence screen capture operations; (f)based on the instructions received by the uploaded screen captureapplication, obtaining screen capture screen graphics data; and (g)sending the screen capture graphics data in a plurality of data packetsto a media upload server.

In another embodiment of the invention, the method further comprises thestep of storing the screen capture graphics data received by the mediaupload server in a media storage database. In another embodiment of theinvention, the method further comprises the step of transmitting thedata packets containing screen capture graphics data by the media uploadserver to a monitoring station for viewing by a monitoring user. Inanother embodiment of the invention, the data packets are formattedusing a protocol that allows at least variable screen capture graphicsdata compression based on available upload bandwidth.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

Various embodiments of the invention will now be described in detail byway of example only with reference to the following drawings:

FIG. 1 is a block diagram of a preferred embodiment of the inventionshowing various components and their interrelationships.

FIG. 2 is a block diagram illustrating an agent workstation according tothe invention, and its connections with other systems.

FIG. 3 is a process flow diagram illustrating an agent registration andlogin process according to an embodiment of the invention.

FIG. 4 is a process flow diagram illustrating operations of a screencapture server component in an embodiment of the invention.

FIG. 5 is a diagram illustrating a protocol used for communicatingscreen capture data, according to an embodiment of the invention.

FIG. 6 is a process flow diagram illustrating a technique for managingbandwidth use during screen capture operations, according to anembodiment of the invention.

FIG. 7 is a process flow diagram illustrating various methods ofterminating screen capture operations, according to various embodimentsof the invention.

FIG. 8 is a block diagram showing various components and theirrelationships, according to an embodiment of the invention, enablingreal-time monitoring of agent performance including screen monitoring.

FIG. 9 is a block diagram illustrating various components forimplementing load balancing, according to an embodiment of theinvention.

FIG. 10 is a block diagram illustrating an exemplary hardwarearchitecture of a computing device used in an embodiment of theinvention.

FIG. 11 is a block diagram illustrating an exemplary logicalarchitecture for a client device, according to an embodiment of theinvention.

FIG. 12 is a block diagram showing an exemplary architecturalarrangement of clients, servers, and external services, according to anembodiment of the invention.

DETAILED DESCRIPTION

The inventor has conceived, and reduced to practice, a system and methodfor recording screen activities of contact center agents that issuitable for cloud-based deployment, and that does not require theinstallation of screen capture software on agent desktops.

One or more different inventions may be described in the presentapplication. Further, for one or more of the invention(s) describedherein, numerous embodiments may be described in this patentapplication, and are presented for illustrative purposes only. Thedescribed embodiments are not intended to be limiting in any sense. Oneor more of the invention(s) may be widely applicable to numerousembodiments, as is readily apparent from the disclosure. Theseembodiments are described in sufficient detail to enable those skilledin the art to practice one or more of the invention(s), and it is to beunderstood that other embodiments may be utilized and that structural,logical, software, electrical and other changes may be made withoutdeparting from the scope of the one or more of the invention(s).Accordingly, those skilled in the art will recognize that the one ormore of the invention(s) may be practiced with various modifications andalterations. Particular features of one or more of the invention(s) maybe described with reference to one or more particular embodiments orfigures that form a part of the present disclosure, and in which areshown, by way of illustration, specific embodiments of one or more ofthe invention(s). It should be understood, however, that such featuresare not limited to usage in the one or more particular embodiments orfigures with reference to which they are described. The presentdisclosure is neither a literal description of all embodiments of one ormore of the invention(s) nor a listing of features of one or more of theinvention(s) that must be present in all embodiments.

Headings of sections provided in this patent application and the titleof this patent application are for convenience only, and are not to betaken as limiting the disclosure in any way.

Devices that are in communication with each other need not be incontinuous communication with each other, unless expressly specifiedother wise. In addition, devices that are in communication with eachother may communicate directly or indirectly through one or moreintermediaries.

A description of an embodiment with several components in communicationwith each other does not imply that all such components are required. Tothe contrary, a variety of optional components are described toillustrate the wide variety of possible embodiments of one or more ofthe invention(s).

Furthermore, although process steps, method steps, algorithms or thelike may be described in a sequential order, such processes, methods andalgorithms may be configured to work in alternate orders. In otherwords, any sequence or order of steps that may be described in thispatent application does not, in and of itself, indicate a requirementthat the steps be performed in that order. The steps of describedprocesses may be performed in any order practical. Further, some stepsmay be performed simultaneously despite being described or implied asoccurring non-simultaneously (e.g., because one step is described afterthe other step). Moreover, the illustration of a process by itsdepiction in a drawing does not imply that the illustrated process isexclusive of other variations and modifications thereto, does not implythat the illustrated process or any of its steps are necessary to one ormore of the invention(s), and does not imply that the illustratedprocess is preferred.

When a single device or article is described, it will be readilyapparent that more than one device/article (whether or not theycooperate) may be used in place of a single device/article. Similarly,where more than one device or article is described (whether or not theycooperate), it will be readily apparent that a single device/article maybe used in place of the more than one device or article.

The functionality and/or the features of a device may be alternativelyembodied by one or more other devices that are not explicitly describedas having such functionality/features. Thus, other embodiments of one ormore of the invention(s) need not include the device itself

Techniques and mechanisms described or reference herein will sometimesbe described in singular form for clarity. However, it should be notedthat particular embodiments include multiple iterations of a techniqueor multiple instantiations of a mechanism unless noted otherwise.

Hardware Architecture

Generally, the techniques disclosed herein may be implemented onhardware or a combination of software and hardware. For example, theymay be implemented in an operating system kernel, in a separate userprocess, in a library package bound into network applications, on aspecially constructed machine, or on a network interface card. In aspecific embodiment, the techniques disclosed herein may be implementedin software such as an operating system or in an application running onan operating system.

Software/hardware hybrid implementation(s) of at least some of theembodiment(s) disclosed herein may be implemented on a programmablemachine selectively activated or reconfigured by a computer programstored in memory. Such network devices may have multiple networkinterfaces that may be configured or designed to utilize different typesof network communication protocols. A general architecture for some ofthese machines may appear from the descriptions disclosed herein.According to specific embodiments, at least some of the features and/orfunctionalities of the various embodiments disclosed herein may beimplemented on one or more general-purpose network host machines such asan end-user computer system, computer, network server or server system,mobile computing device (e.g., personal digital assistant, mobile phone,smartphone, laptop, tablet computer, or the like), consumer electronicdevice, music player, or any other suitable electronic device, router,switch, or the like, or any combination thereof. In at least someembodiments, at least some of the features and/or functionalities of thevarious embodiments disclosed herein may be implemented in one or morevirtualized computing environments (e.g., network computing clouds, orthe like).

Referring now to FIG. 10, there is shown a block diagram depicting acomputing device 1000 suitable for implementing at least a portion ofthe features and/or functionalities disclosed herein. Computing device1000 may be, for example, an end-user computer system, network server orserver system, mobile computing device (e.g., personal digitalassistant, mobile phone, smartphone, laptop, tablet computer, or thelike), consumer electronic device, music player, or any other suitableelectronic device, or any combination or portion thereof. Computingdevice 1000 may be adapted to communicate with other computing devices,such as clients and/or servers, over a communications network such asthe Internet, using known protocols for such communication, whetherwireless or wired.

In one embodiment, computing device 1000 includes central processingunit (CPU) 1002, interfaces 1010, and a bus 1006 (such as a peripheralcomponent interconnect (PCI) bus). When acting under the control ofappropriate software or firmware, CPU 1002 may be responsible forimplementing specific functions associated with the functions of aspecifically configured computing device or machine. For example, in atleast one embodiment, a user's [[[personal digital assistant (PDA) maybe configured or designed to function as an intelligent automatedassistant]]] system utilizing CPU 1002, memory 1001, 1020, andinterface(s) 1010. In at least one embodiment, CPU 1002 may be caused toperform one or more of the different types of functions and/oroperations under the control of software modules/components, which forexample, may include an operating system and any appropriateapplications software, drivers, and the like.

CPU 1002 may include one or more processor(s) 1003 such as, for example,a processor from one of the Intel, ARM, Qualcomm, and AMD families ofmicroprocessors. In some embodiments, processor(s) 1003 may includespecially designed hardware (e.g., application-specific integratedcircuits (ASICs), electrically erasable programmable read-only memories(EEPROMs), field-programmable gate arrays (FPGAs), and the like) forcontrolling operations of computing device 1000. In a specificembodiment, a memory 1001 (such as non-volatile random access memory(RAM) and/or read-only memory (ROM)) also forms part of CPU 1002.However, there are many different ways in which memory may be coupled tothe system. Memory block 1001 may be used for a variety of purposes suchas, for example, caching and/or storing data, programming instructions,and the like.

As used herein, the term “processor” is not limited merely to thoseintegrated circuits referred to in the art as a processor, a mobileprocessor, or a microprocessor, but broadly refers to a microcontroller,a microcomputer, a programmable logic controller, anapplication-specific integrated circuit, and any other programmablecircuit.

In one embodiment, interfaces 1010 are provided as interface cards(sometimes referred to as “line cards”). Generally, they control thesending and receiving of data packets over a computing network andsometimes support other peripherals used with computing device 1000.Among the interfaces that may be provided are Ethernet interfaces, framerelay interfaces, cable interfaces, DSL interfaces, token ringinterfaces, and the like. In addition, various types of interfaces maybe provided such as, for example, universal serial bus (USB), Serial,Ethernet, Firewire™, PCI, parallel, radio frequency (RF), Bluetooth™,near-field communications (e.g., using near-field magnetics), 802.11(WiFi), frame relay, TCP/IP, ISDN, fast Ethernet interfaces, GigabitEthernet interfaces, asynchronous transfer mode (ATM) interfaces,high-speed serial interface (HSSI) interfaces, Point of Sale (POS)interfaces, fiber data distributed interfaces (FDDIs), and the like.Generally, such interfaces 1010 may include ports appropriate forcommunication with appropriate media. In some cases, they may alsoinclude an independent processor and, in some in stances, volatileand/or non-volatile memory (e.g., RAM).

Although the system shown in FIG. 10 illustrates one specificarchitecture for a computing device 1000 for implementing the techniquesof the invention(s) described herein, it is by no means the only devicearchitecture on which at least a portion of the features and techniquesdescribed herein may be implemented. For example, architectures havingone or any number of processors 1003 can be used, and such processors1003 can be present in a single device or distributed among any numberof devices. In one embodiment, a single processor 1003 handlescommunications as well as routing computations. In various embodiments,different types of features and/or functionalities may be implemented ina system according to the invention that includes a client device (suchas a personal digital assistant or smartphone running client software)and server system(s) (such as a server system described in more detailbelow).

Regardless of network device configuration, the system of the presentinvention may employ one or more memories or memory modules (such as,for example, memory block 1020) configured to store data, programinstructions for the general-purpose network operations and/or otherinformation relating to the functionality of the embodiments describedherein. The program instructions may control the operation of anoperating system and/or one or more applications, for example. Thememory or memories may also be configured to store data structures,domain and topic information, social network graph information, useractions information, and/or other specific non-program informationdescribed herein.

Because such information and program instructions may be employed toimplement the systems/methods described herein, at least some networkdevice embodiments may include nontransitory machine-readable storagemedia, which, for example, may be configured or designed to storeprogram instructions, state information, and the like for performingvarious operations described herein. Examples of such nontransitorymachine-readable storage media include, but are not limited to, magneticmedia such as hard disks, floppy disks, and magnetic tape; optical mediasuch as CD-ROM disks; magneto-optical media such as optical disks, andhardware devices that are specially configured to store and performprogram instructions, such as read-only memory devices (ROM), flashmemory, solid state drives, memristor memory, random access memory(RAM), and the like. Examples of program instructions include bothmachine code, such as produced by a compiler, and files containinghigher level code that may be executed by the computer using aninterpreter.

In some embodiment, systems used according to the present invention maybe implemented on a standalone computing system. Referring now to FIG.11, there is shown a block diagram depicting an architecture forimplementing one or more embodiments or components thereof on astandalone computing system. Computing device 1000 includes processor(s)1003 that run software for implementing for example an email or otherdocument management client application 1100. Input device 1112 can be ofany type suitable for receiving user input, including for example akeyboard, touchscreen, microphone (for example, for voice input), mouse,touchpad, trackball, five-way switch, joy stick, and/or any combinationthereof. Output device 1711 can be a screen, speaker, printer, and/orany combination thereof. Memory 1710 can be random-access memory havinga structure and architecture as are known in the art, for use byprocessor(s) 1603 for example to run software. Storage device 1711 canbe any magnetic, optical, and/or electrical storage device for storageof data in digital form; examples include flash memory, magnetic harddrive, CD-ROM, and/or the like.

In some embodiments, the system of the present invention is implementedon a distributed computing network, such as one having any number ofclients and/or servers. Referring now to FIG. 12, there is shown a blockdiagram depicting an architecture for implementing at least a portion ofan intelligent automated assistant on a distributed computing network,according to at least one embodiment.

The arrangement shown in FIG. 12, any number of clients 1210 areprovided; each client 1210 may run software for implementing client-sideportions of the present invention. In addition, any number of servers1220 can be provided for handling requests received from clients 1210.Clients 1210 and servers 1220 can communicate with one another viaelectronic network 1200, which may be in various embodiments any of theInternet, a wide area network, a mobile telephony network, a wirelessnetwork (such as WiFi, Wimax, and so forth), or a local area network (orindeed any network topology known in the art; the invention does notprefer any one network topology over any others). Network 1200 may beimplemented using any known network protocols, including for examplewired and/or wireless protocols.

In addition, in some embodiment, servers 1220 can call external services1230 when needed to obtain additional information, to refer toadditional data concerning a particular document or message, or toaccess for example curated data sources (for example, Wolfram Alpha™) inorder to assist in building rich ontologies. Communications withexternal services 1230 can take place, for example, via network 1200. Invarious embodiments, external services 1230 include web-enabled servicesand/or functionality related to or installed on the hardware deviceitself For example, in an embodiment where email client 1100 isimplemented on a smartphone or other electronic device, client 1100 canobtain information stored in an email archive or a document store in thecloud or on an external service 1230 deployed on one or more of aparticular enterprise's or user's premises.

In various embodiments, functionality for implementing the techniques ofthe present invention can be distributed among any number of clientand/or server components. For example, various software modules can beimplemented for performing various functions in connection with the present invention, and such modules can be variously implemented to run onserver and/or client components.

Detailed Description of Embodiments

In a preferred embodiment, and referring to FIG. 1, contact center 100is a client of a cloud-based screen capture solution according to theinvention. As is typical of contact centers, center 100 receives inbound(or makes outbound) calls to (from) customers, who may be using mobiledevices 172 or conventional telephones 171 to connect. Telephones 171can use conventional time-division multiplexed (TDM) telephone (or plainold telephony services—POTS) to make connections via public switchedtelephone network (PSTN) 161, or they may use voice over Internetprotocol (VOIP) telephony, both of which are well known in the art. PSTN161 may also be a wireless mobile telephony network servicing consumersthat use mobile devices 172, and call centers 100 (again, “call center”,“contact center”, and “center” may be used interchangeably throughoutthis document) typically accept calls from any telephones, whetherlandlines, Internet phones, or mobile phones (or even payphones, forexample), although they are generally connected to only one or two PSTNnetworks 161, with customers using other networks reaching them throughuse of interconnect features built in to all telecommunications networkstoday. Also, centers 100 may typically receive or make calls over theInternet 160 directly when customers are using VOIP telephones orsoftware-based communications means such as an instant messaging client,Skype™, email servers, and the like. It should be appreciated by onehaving ordinary skill in the art of modern contact centers that meansare well established in the art for centers 100 to handle any of themany interaction types by which consumers now typically interact withcontact centers 100, including but not limited to email, chat, instantmessaging (IM), short message system (SMS), social media, and of coursetelephony of various types.

Center 100 receives “calls” normally at an automated call distributor(ACD) 120, a kind of specialized telephony switch (actually, aspecialized private branch exchange or PBX) that not only can terminatevoice calls arriving from PSTN 161 or Internet 160 but also is equippedwith special software for queuing calls, transferring calls betweenstations within a center 100 (and often between ACDs 120 operating atdifferent centers 100 of a single enterprise), and recording call detailrecords concerning when calls arrived, where they were sent, and howlong they spent at the various points within center 100 where they wereterminated. It is common in the art today for ACD 120 to connect, via acomputer-telephony integration (CTI) link, to CTI server 121, such as aTServer from Genesys Telecommunications Laboratories, Inc. CTI server121 receives notification events from ACD 120 concerning calls residingin ACD 120, and typically CTI server 121 sends standardized forms ofthese events to various client applications or devices within center121, so that these applications can respond to telephony events.Examples of telephony events include arrival of a call at an ACD queue,establishment of a call at an agent phone 123, abandonment of a callwhile in queue, termination of a call at agent phone 123, and so forth.

Media types other than phone calls typically do not arrive at ACD 120 inmodern centers 100, but instead arrive at a specialized softwareapplication designed to handle interactions of a specific type. Forinstance, email server 111 will typically handle incoming emails, chatserver 112 will typically handle incoming chat sessions, instantmessaging server 113 will handle incoming IM sessions, short messagesystem (SMS) interface 114 will typically handle incoming SMS messagesfrom PSTN 161 or Internet 160, and social media integration server 115will typically handle inbound social media interactions. All of theseservers and applications are exemplary in nature, however, as there aremany variations that modern centers 100 can use to receive inboundcommunications in these and other media types, and of course all of themcan equally handle outbound interactions of the particular type (inboundwill generally be used for exemplary purposes, for simplicity, butnothing in the invention is limited specifically to inboundinteractions). Also, in modern contact centers 100 non-telephonyinteractions are generally handled by an interaction server 125 ratherthan directly by CTI server 121. Interaction server 125 serves ananalogous purpose for these media types as CTI server 121, although theyoften have additional, media-specific functions that in telephonyinteractions are handled by ACD 120 (for instance, in some casesinteraction server 125 handles queuing of inbound non-telephonicinteractions). It will be appreciated by one having ordinary skill thein the art that CTI server 121 and interaction server 125 are eachexamples of a general-purpose communication server, the function ofwhich is to send notifications to clients and receive instructions fromclients regarding communications of one or more media types.

Interactions in center 100 are often delivered to agent phones 123 oragent desktops 122 by basic queuing services provided by ACD 120 orinteraction server 125 (depending on media type). But in more advancedcenters, a specialized interaction router 130 is sent routing requestsfrom either or both CTI server 121 or interaction server 125. When itreceives these requests, interaction router 130 executes a scriptcommonly known as a routing strategy to determine where to send theinteraction in question. Interaction router 130 generally keeps track ofthe state of readiness of each of a plurality of agents, each associatedwith a desktop computer 122 and a phone 123, although sometimes thisfunction is performed by a separate statistical server (not shown). Oncea target is selected, instructions to route the interaction to thattarget are sent to the appropriate server (CTI server 121 or interactionserver 125), which then sends the specific request (usually in amedia-specific data protocol) to the appropriate media handling system(ACD 120, email server 111, and so forth). Note that in some centers 100ACD 120 and one or more other media-specific services are delivered byan generalized media server (not shown); center 100's specificarchitecture and arrangement of components is illustrative only andessentially any internal structure of center 100 may be used accordingto the invention (since what is new lies outside of the center 100). Insome cases agents may reside or work outside of center 100, generallyworking with a PC 170 and a landline telephone 171. One increasinglycommon variation of this approach is the widespread and increasing useof home agents to provide for more flexible staffing, lower costs, andbetter employee relations. Additionally, with the emergence of “smartphones”, it is possible for agents to handle customer calls via mobiledevice 172, which could be a mobile phone equipped with the ability torun applications at the same time as handling calls (that is, a smartphone), or a tablet computing device.

Most contact centers 100 have one or more contact center databases 131that store data pertaining to operations of the contact center 100.Contact center database 131 typically stores call detail records (whennot stored directly by ACD 120), customer records useful for contactcenter operations, and configuration data pertaining to contact center100, such as agent names, login credentials, skill assignments, and thelike. There are many variations of data storage in contact centers 100,and in most cases there is more than one database 131. Onegeneral-purpose contact center database 131 is shown in FIG. 1 again asexemplary of a typical contact center 100, and nothing in the inventionshould be considered limited thereby. Finally, configuration server 132is a component within a typical contact center 100 that is oftensubsumed into one or more other components but if highlighted here as aseparate component for clarity of exposition. Configuration server 132is generally the point through which all configuration-related requestsare passed, even though generally all configuration-related data isstored in database 131. Usually this is done to allow configurationserver 132 to verify access privileges of any persons requesting to viewor change configuration data, to validate configuration data prior toentering it into database 131 (not least because database 131 errormessages are typically general, whereas error messages fromconfiguration server 132 will tend to be framed in “contact centerlanguage”, such as “agent cannot have the same skill twice”). Also,configuration server 132 usually has the role of notifying all affectedcomponents when any configuration change is made, which often makes itpossible for contact centers 100 to be operated in a quite flexible way.

According to a preferred embodiment of the invention, contact center 100is not equipped with an on-premise screen capture capability (also nocall recording capability is shown, and typically it will be operated asa cloud-based service in conjunction with the cloud-based screen capturesolution of the invention). According to the embodiment, screen captureserver 140 is operated separately (or off premise) from center 100,typically by a third party. Screen capture server 140 manages theoverall screen capture process, according to the embodiment, includingcommunicating with CTI server 121 and interaction server 125, asappropriate, to receive notifications of interaction arrivals andterminations, to receive requests to capture screens associated with aninteraction (not all interactions will be “screen captured” in allcontact centers 100, but some form of statistical sampling or on-demandscreen capturing may be used instead, enabled by communications betweenCTI server 121 or interaction server 125 and screen capture server 140).Web server 150 is a conventional web server known in the art, such asMicrosoft Internet Information Server or Apache Web Server; similarly,web application server 151 is a conventional web application server suchas Tomcat or JBoss, and serves to host web applications 152 that areaccessed by users via conventional web browsers interacting with webserver 150. These are conventional web components, which in anembodiment of the invention are used to host and deliver webapplications necessary to provide a cloud-based, “zero footprint” screencapture service accessed through an agent's browser. “Zero footprint”here is used in the conventional sense that applies in the art ofenterprise software, where it means “does not require any permanentinstallation of software or any manual installation steps”. Specificdetails of how web server 150 and web application server 151 areprovided below.

Media upload server 141 is normally, although not necessarily, acloud-based server that receives uploads of call recordings and screencaptures from contact center 100 (although it should be understood thatin some embodiments media upload server 141 may receive screen capturesfrom multiple unrelated centers 100). Uploaded call recordings andscreen capture recordings are stored in media storage database 142.Database 142 is in some embodiments a conventional relational databasemanagement system such as Oracle, while in other embodiments it is adistributed, non-relational data storage system such as Hadoop. Itshould be appreciated by one having ordinary skill in the art of datasystems that the invention is not limited to any particular form orarchitecture of database, but may be implemented using any data storagesystem that provides the required scale and security features needed fora particular implementation (and of course there are otherconsiderations that might drive such a choice as well).

FIG. 2 is a block diagram illustrating an agent workstation 200according to the invention, and its connections with other systems. Insome embodiments, agent workstation is deployed onsite at a contactcenter 100 (like the agent workstation containing agent PV 122 and agentphone 123), while in other embodiments agent workstation 200 is deployedoutside contact center 100, for example at an agent's home or in a smalloffice (analogous to agent PC 170 and agent phone 123 in FIG. 1). Asshown in FIGS. 1 and 2, agent workstation 200 may be coupled via a datanetwork (for example Internet 160 or a corporate network) to web server150, media upload server 141, and screen capture server (SCS) 140 andoptionally to a backup SCS 250).

Agent workstation 200 comprises a computer that is connected to at leastone monitor 240 or equivalent graphical interface element. According toa preferred embodiment of the invention, agent workstation furthercomprises an operating system 235, such as any of the Microsoft Windowsversions, Mac OS/X, some flavor of Linux, or indeed any operating systemcapable of hosting a browser 210 and other independent programs, and ofdriving graphical content to a monitor 240 or equivalent using videodrivers 232. It will be appreciated by one having ordinary skill in theart of operating systems that video drivers 232 are sometimes consideredpart of operating system 235, and sometimes are considered as standalonesoftware modules. Either mode is suitable according to the invention.Agent workstation further comprises one or more of random access memory(RAM) 231 and hard disk drives (HDD) 230, although any suitable memorytechnology, including but not limited to Flash memory andthree-dimensional semiconductor memory (for example memristors) may beused without departing from the scope of the invention.

In some embodiments more nontraditional agent workstations may be used,such as tablet computing devices like Apple's iPad™ series. In theseembodiments, each of the components shown in FIG. 2 will still bepresent, although possibly with other names, and possibly combined. Forexample, on an iPad™, RAM 231 and HDD 230 are replaced by a singlememory system based on solid state Flash memory, and monitor 240 isintegral to agent workstation (it is the front side of the iPad™). Itwill be appreciated by those having ordinary skill in the art ofcomputer engineering that any computing device equipped with a screen(without which “screen capture” does not make sense!), at least onevideo driver 232, some form of memory 230, 231, and operating system 235(iOS in the case of an iPad™), and at least a browser 210 capable ofhosting digitally signed software and allowing for download ofexecutable components with suitable security precautions.

Agent workstation will, when screen capture operations are taking placein accordance with the invention, further comprise at least one runningbrowser 210, which while an agent is logged in to contact center 100will host an applet 211 or other downloadable code module, and a screencapture module 220. Screen capture module 220 is coupled via theInternet 160 or another network to media upload server 141, in order tobe able to upload content from screen capture operations to MUS 141.

In some embodiments it is only desirable to record screen capture videofrom an agent's computing device 200 while the agent is on a call with acustomer, since during times when an agent is not on a call with acustomer (or performing work related to a customer call), they may beinvolved in activities that are not necessary to record. In some cases,as when agents are working at home, it may even be potentially illegalto record screen activities on a private computing device 200 when workis not being performed. In some cases, though, it may be desirable torecord screen capture videos even when no call is in progress (forinstance, when an agent is using a company-owned computer and is doingwork that needs to be measured essentially all the time the agent islogged in to her computing device 200).

In order for a “zero footprint” screen capture system according to theinvention to work, a means must usually be available to associate anagent's computing device 200 with the same agent's phone 171, 172, or123. This is because, quite often, the first indication that a systemoperating according to the invention will have of the arrival of atelephone call at an agent, and because often it will only be desirableto record screen captures while a call is in progress. Such a meanswould not be necessary in cases where screen capture recording are to bemade without regard to the state of telephonic activity at agentworkstation 200; for instance, if insurance claim adjustment work notinvolving phone calls is to be monitored using screen capturerecordings.

Accordingly, FIG. 3 is a process flow diagram illustrating an agentregistration and login process according to an embodiment of theinvention. In step 301, which is typically executed only once when anagent first is added to the system (or when an agent changesworkstations 200), a new agent initiates registration using a web pagedisplayed in browser 210. The web page is served by web server 150,which invokes a registration application 152 hosted by web applicationserver 151. In a preferred embodiment, web application server 151provides an agent application 152 that is used for all agent activitiesconducted according to the invention. Such web-based agent applicationsare typical and well known in the art, and may use methods such asproviding a series of tabs to allow a rich variety of functionality tobe made available to agents within a single application while keepingthe user interface ergonomically satisfactory. Of course, agent webapplication 152 can be implemented using any technology suitable forbuilding web-based user interfaces, including but not limited to theMicrosoft .NET Framework, Microsoft Silverlight technology, ActiveServer Pages, Java applications, Javascript code, PHP code, Adobe Flash,HTML 5, and the like—a person having ordinary skill in the art of webinterface design will appreciate that there is a rich variety oftechnologies and tools available to build rich user interfaces, any ofwhich may be used according to the invention without departing from thescope of the invention. When an agent registers in step 301, normallythe agent will be assigned an agent identification number (oftenreferred to as AgentID), although in many embodiments an agent will havebeen assigned an AgentID by ACD 120, and this AgentID will have beenprovided to the agent before step 301, so that the agent may enter theAgentID in step 301. Either way, at the conclusion of step 301 anassociation is made between workstation 200 (generally—but notnecessarily—based on its IP address) and a particular agent (based onAgentID).

In an embodiment, after an agent registers in step 301, a registrationapplet is uploaded under control of agent web application 152. Sincegenerally the applet will be new to a particular agent/workstationcombination (since the agent just registered for the first time from theparticular workstation 200), in step 303 the agent will be presentedwith a popup or dialog box that informs the agent that the applet is asigned application, and asking whether the agent wishes to accept thedigital certificate associated with the application. Normally, when anagent has been trained on what to expect, an agent will select “alwaystrust the source of the certificate” or an equivalent choice, whichmeans that future uploads of applets from web server 150 will nottrigger a certificate acceptance prompt to the agent. Steps 302-303 arenot mandatory according to the invention, as there are other ways knownin the art to establish web server 150 or web application server 151 astrusted sources for signed applications, any of which may be used. And,even if no equivalent of these steps is performed, one can still carryout the invention, with the only difference being that instead of “zerofootprint” the screen capture service will have a very small footprint,requiring an extra step of accepting download of an applet each time anagent logs in. Once steps 301-303 are completed, an agent is fullyregistered and the agent's AgentID is associated with workstation 200,and accordingly the agent is ready to use workstation 200 to handlecustomer calls (incoming or outgoing). In some cases, an AgentID istightly associated with a particular workstation 200, but according tothe invention it is possible to allow agents to use their AgentID andwork at any workstation 200 (as long as there is a way to associateAgentID and workstation 200 address at the time work is performed, thereis no problem). Also, generally each particular phone 123, 171, or 172is associated with a particular workstation 200. Note that manyvariations on certificate registration processes are possible accordingto the invention; for example, in some embodiments certificates areviewed and accepted by agents when the agents initially configure theirworkstations for contact center work, and no mention is made of anyscreen capture application during such registration (although typicallynon-technical means such as employment contracts will advise agents thattheir actions may be monitored as well as their audio). Thus in someembodiments of the invention agents' activities may be monitored viascreen capture without the agents' ever having any indication that suchactivities are taking place (that is, truly “zero footprint” screencapture operations are possible according to the invention).

Each time an agent begins a work session, in step 304, the agentinitiates login via web application 152. Login is typically accomplishedby entering the agent's AgentID and a password. Logging in as in step303 creates an immediate association between the agent's AgentID and theaddress of the workstation 200 where the login takes place. This allowsevents pertaining to a phone 123 to be associated with actions taken onworkstation 200, and both to be associated to an agent identified by aparticular AgentID, and thus allows all of the events and actorsinvolved in serving a customer to be correlated with each other. Afteran agent logs in, in step 304, in step 305 screen capture control applet211 is uploaded via web application 152 to workstation 200. Since inmost cases in step 303 the web application server 151 had beenpermanently approved as a source for delivering digitally signed code,screen capture control applet 211 is uploaded in the background withoutany agent action or awareness required. Note that while the term“applet” is used here, it does not necessarily imply a “Java applet”,but refers to any executable code that can be signed, downloaded via aweb page, and executed within a browser 210 on the target machine 200.When screen capture control applet (SCCA) 211 is uploaded, it runs andimmediately, in step 306 screen capture control applet 211 connects toone or more screen capture server instances 140, 250. In someembodiments, SCCA 211 attempts to connect first to a primary SCS 140,and if it succeeds then it does not connect to any others; if connectionto SCS 140 fails, SCCA 211 would then attempt to connect to a backup SCS250. In other embodiments, SCCA 211 will connect, if possible, to bothSCS 140 and backup SCS 250, in order to use a “hot standby” mode ofredundancy. It should be appreciated by one having ordinary skill in theart of distributed computing that there are many arrangements that canbe made to provide a high degree of confidence that SCCA 211 will beable to connect, and remain connected, to at least one SCS 140, and anyof these various approaches may be adopted without departing from thescope of the invention. Additionally, while normally SCCA 211 will, whenuploaded, contain information provided by web application server 151that describes connection parameters needed to connect to SCS 140 instep 306 (for example, a hostname and port combination that describesparticular port on a particular machine where SCS 140 will be listeningfor new connections), in some embodiments connection information may bestored locally on workstation 200 or acquired in some other way, withoutdeparting from the scope of the invention.

Once SCCA 211 is downloaded and connected to at least one SCS 140, itchecks (step 307) whether any screen capture module 220 is present onworkstation 200. In some cases, as will be seen below, screen capturemodule 220 is left on workstation 200 after its initial installation(while in other cases it is deleted after it is used, to be downloadedeach time it is needed). It is because of this that the possibilityexists that screen capture module 220 is already present on workstation200, and hence SCCA 211 checks first. If in fact screen capture module220 is already installed, step 309 is executed next; but if screencapture module 220 is not already installed, in step 308 SCCA 211downloads and installs into host operating system 235 screen capturemodule 220. Screen capture module 220 is executable code capable ofbeing installed at least into memory 231 or installed directly onto harddrive 230, which may be a standalone executable, a service that can beinstalled directly into operating system 235 (for instance, a Windowsservice), or any other form known in the art by which executable codecan be installed, even temporarily, on a workstation 200 using operatingsystem 235. In a preferred embodiment, screen capture module 220 is astandalone Windows executable that is downloaded by SCCA 211 andinstalled (because SCCA 211 is a signed application, it can exercise aprivilege level sufficient to allow it to install programs ontoworkstation 200) and run as a Windows service. Once screen capturemodule 220 is installed in step 308, step 309 is executed. In step 309,screen capture control applet 211 starts screen capture module 220 andpasses at least one address of a media upload server 141 to it. Oncestartup of screen capture module 220 is confirmed, in step 310 SCCA 211notifies SCS 140 that it is ready to conduct screen capture operationson request. While the process of actually starting and controllingscreen capture operations will be discussed with respect to FIG. 4, itis helpful here to discuss what happens when an agent ends a worksession and logs out. In step 311, when an agent logs out, or whenotherwise directed by SCS 140, SCCA 211 stops screen capture module 220,optionally uninstalls or deletes it, and then terminates itself,returning workstation 200 to the condition it was in prior to agentlogin in step 304 (with the possible exception of having left behind acopy of screen capture module 220, which is an option that may or maynot be used, at the discretion of each entity using a system accordingto the invention).

FIG. 4 is a process flow diagram illustrating operations of screencapture server 140 according to a preferred embodiment of the invention.In initial step 400, SCS 140 is started. Then, in step 401, SCS 140connects to CTI server 121 and interaction server 125. In someembodiments, SCS 140 will connect to a plurality of CTI servers 121 anda plurality of interaction servers 125; according to the invention, anynumber of each may be connected to (including for example two CTIservers 121 and zero interaction servers 125); what is important is thata connection is made to each server 121, 125 from which events are to bereceived and from which requests to start or stop screen capturerecording will be received. Once started and connected to any requiredCTI servers 121 and interaction servers 125, SCS 140 waits in step 402for connections from screen capture control applets 211 (initiation ofsuch connections was discussed with reference to FIG. 3 above). Eachtime a screen capture control applet 211 attempts to connect, in step403 the applet is validated (for example, did the request to connectcome from a known workstation 200?) and possibly authenticated(typically using an application identifier and an encrypted password orpasscode that has been preconfigured); if validation/authenticationfails, execution passes back to step 402. When a screen capture controlapplet 211 has successfully connected and been validated in step 403,then in step 404 default rules for handling the particular agentassociated with the workstation from which SCCA 211 connected areoptionally loaded by SCS 140. Agent-specific rules could comprise rulessuch as “always record every call handled by this agent and capture theassociated screen activities”, or “record and capture calls and screenactivity for 25% of calls handled by this agent, and provide the agent a‘push to record’ button to allow this agent to initiate recordingindependently”, or “only record VIP calls to this agent”; it will beappreciated that any number of possible rules can be specified, usingany desired rule formats—ranging from simple plain text with delimitersto complex data structures loaded from a database and containing manyrules—without departing from the scope of the invention. According to apreferred embodiment of the invention, and in keeping with rulesmanagement approaches commonly used in contact centers, defaultsite-wide rules may also be established, so that for agents that do nothave agent-specific rules, these default site-wide rules will be used.Furthermore, in some embodiments recording rules can also be establishedfor different types of interactions, and rules can be specified thatgovern conflicts between rules (for example, “when agent-specific rulesand call-specific rules conflict, always elect to record whenever eitherrule requires it”, or “always give call-specific rules priority, andoverride agent-specific rules when a non-zero set of call-specific rulesexists”).

Once step 404 has been completed, the screen capture recording system isfully prepared. In some embodiments, all activity on a logged in agent'sworkstation 200 will be recorded, regardless of whether an interactionis in progress or not; for these embodiments, recording starts afterstep 404 and continues until an agent logs out. Otherwise, in step 405SCS 140 waits for communications events to arrive from one or more ofCTI servers 121 and interaction servers 125. When an event is received,in step 406 SCS 140 determines whether the event received corresponds toa beginning of a new session or interaction. If it does, then in step407 optional interaction-specific (i.e., call-type specific) rules maybe loaded. Then, in step 408, SCS 140 evaluates all active rules (forexample, site-specific, agent-specific, call-type specific and evensingle-session-specific) and applies any rules conflict rules (that is,rules that themselves govern how to resolve conflicts between otherrules), to determine whether the received event satisfies any rule thatrequires screen capture operations to start. If they do, then in step409 SCS 140 sends a “start” command to SCCA 211, and optionally includeswith the command data pertaining to a media upload server 141 to whichany resulting screen capture data is to be uploaded. SCCA 211 passesdata pertaining to media upload servers 141 to screen capture module 220either when it starts screen capture module 220 (as described above) orwhen a new recording is started (as just described), or both. In someembodiments, screen capture module 220 is provided with a MUS 141address on startup so that, if no MUS 141 data is provided with a startcommand, it is still possible to capture and upload screen data. In thisway, “command by override” is implemented, since if—for load balancingor any other purpose—SCS 140 determines that a specific MUS 141 shouldbe used for a specific recording, it may send the appropriate MUS 141connection data with the start command; otherwise, it need not send anyMUS 141 data and screen capture module 220 will upload to the MUS 141whose connection data it was given at startup. After step 408 andoptionally step 409, in step 410 SCS 140 determines whether the receivedevent triggers any rule to stop recording and, if so, in step 411 itsend an appropriate command to the relevant SCCA 211. Then, in step 412,SCS 140 checks whether the received event corresponds to an agent logoutor workstation 200 shutdown event (or indeed a browser 210 shutdownevent), and if so sends, in step 413, a stop or kill signal to SCCA 211to instruct it to carry out its termination process (step 311 in FIG.3). After handling a received event by working through steps 406-413,control returns to step 405, and SCS 140 waits for another event(although it should be noted that event handlers could be operated eachin its own thread, according to techniques well known in the art ofevent-based programming, and therefore steps 406-413 could proceed in anindependent thread while in step 405 SCS continues without interruptionto await new incoming events from CTI servers 121 or interaction servers125.

With the detailed explanations pertaining to FIGS. 3 and 4 in mind,operation of a system according to the invention can be understoodclearly. Walking through an example, first a registered agent logs inusing a browser-based interface, and makes herself ready to answer callsfrom customers. While logging in, and without any action required on thepart of the agent, the web application through which the agent logs indownloads an applet that manages screen capture operations. The appletconnects to one or more screen capture servers, which are in turnconnected to various media servers (such as CTI server 121 orinteraction server 125) and are thus able to receive notification eventspertaining to customer interactions. The screen capture control applet211 then causes the download and installation (if necessary) of a screencapture module 220 that will be used to actually interact with videodrivers 232 to capture video data (i.e., to “capture screen activitydata”; screen capture techniques are well established in the art). Then,when a customer calls in, it may be routed to an agent, and as it isbeing sent to the agent's phone, a data message is typically sent to theagent's desktop (from CTI server 121 in this example) that causes ascreen pop to occur. At substantially the same time, screen captureserver 140 receives notification of the call's delivery to an agent, andbased on one or more rules determines that the call should be recorded,including any screen activity undertaken by the agent. Screen captureserver 140 therefore sends a message to screen capture control applet211 telling it to start screen capture operations, and SCCA 211 sends astart message to screen capture module, which connects to a media uploadserver and begins transmitting captured screen activity data. When thecustomer call completes, again a message is sent by CTI server 121 toscreen capture server 140 announcing the end of the call; screen captureserver 140 sends a stop command to SCCA 211, which in turn tells screencapture module 220 to stop capture operations. Depending onconfiguration, screen capture module 220 may continue to uploadalready-captured video or graphics data to media upload server and, uponcompletion of all buffered uploads, it then ceases activity and waitsfor another call (actually, it waits for another start message from SCCA211). When the agent later logs out, screen capture module 220 may beuninstalled and deleted, or may simply cease operating until the agentlogs back in; SCCA 211 usually unloads when the agent logs out andthereby leaves the web application used for agent contact center work.

FIG. 5 is a diagram illustrating an exemplary protocol used foruploading captured screen graphics data to media upload server 141,according to an embodiment of the invention. It is generally necessaryto break screen capture data into “chunks” of manageable size, to easethe management of bandwidth between screen capture module 220 and mediaupload server 141. Accordingly, a protocol such as that illustrated inFIG. 5 that allows for transmission of screen capture data in a flexibleway is desirable. According to a preferred embodiment of the invention,screen capture data is sent as a succession of “jpg” files, which whenviewed collectively and in sequence represent a video of what an agentdid on workstation 200 during one or more customer calls (or while doingnon-call-related work). Screen capture data is packaged, according tothe protocol known as “BG300”, into archive files 500 with a fileextension of “.ar”. Each archive file 500 comprises a plurality ofrecord files 501 with file extension “.rec”, each of which represents asingle contiguous block of recorded video. In some cases a succeeding.rec file will have video that starts immediately after the conclusionof a previous .rec file, and the two (and potentially more) filestogether represent a single larger contiguous video recording. However,in some cases one .rec file may end at a particular time, and animmediately subsequent .rec file might start at some later time; thiscan occur, for instance, when there is an actual pause in action duringa call or other period to be recorded. In a preferred embodiment, ifnothing is changing on an agent's desktop (for instance if an agent hasstepped away to confer with a colleague), then nothing is recorded byscreen capture module 220, and a period of “dead air” will occur whichwould make a natural boundary for separating two .rec files, one endingat the beginning of the idle period and the other starting at the end ofthe idle period.

According to a preferred embodiment, each .rec file begins with a .recheader 510, which contains information pertaining to the entire .recfile. A .rec header 510 will typically comprise an identifier 511 thatuniquely identifies the file as a .rec file for use with the invention,a picture width 512 that specifies a width (typically, but notnecessarily, in pixels), a picture height 513 that specifies a height(also typically, but not necessarily, in pixels), a scaling factorcommonly defined as 100*percent scaling relative to an initial picturesize (so that 50 means the captured video is scaled to 50% of itsoriginal size), an initial timestamp 515, a frame rate 516 thatspecifies a number of frames that were recorded per unit time, and acolor format 517 that typically uses a single bit or a pair of bits todistinguish between two or four alternative color formats that might beused when recording video (there could be more variations, as manydifferent color coding schemes are known in the art of computergraphics, and color format field 517 needs to be at least large enoughto allow specification of all color formats that might be used in aparticular embodiment). In a preferred embodiment of the invention,identifier 511 corresponds to a magic number selected so as to uniquelyidentify record file 501 as a data file corresponding to a specificprotocol (in this case, the protocol defined by FIG. 5).

Each record file 501 continues, following its header 510, with a seriesof frames 520. Each frame corresponds to a single snapshot of an agent'sscreen on monitor 240 at workstation 200, and accordingly each recordfile 501 will contain a number of frames 520 equal to its frame rate 516(recorded in record file header 510) times the length of time of thevideo recording contained in record file 501. Each frame begins with aframe header 521 that stores data applicable to the entire frame. In apreferred embodiment, frame header 521 comprises at least an identifier522, a type identifier 523, a timestamp 524, and a number of tiles 525.Identifier 522 again uses a magic number to positively identify frame520 as being a frame corresponding to a specific protocol, in this casethe protocol illustrated in FIG. 5. It will be appreciated that use of“magic numbers” to uniquely identify content types is a well-knowntechnique in the art of data encoding, and that any method of positivelyidentifying payloads of record files, frames, and indeed tiles withinframes may be substituted without departing from the scope of theinvention. Type identifier 523 is used to distinguish between two typesof frames 520—those that record a position for a mouse cursor and thosethat don't. A mouse cursor is a well known element of computer userinterfaces, and in some embodiments it is desirable to include alocation of a mouse cursor and its visibility so that a correspondingmouse cursor can be shown (or not) on a screen being viewed by a personviewing a video replay of a series of screen captures that display whathappened on an agent's monitor 240 during a customer call. For thoseframes which are to include mouse cursor information (as indicated bythe value of type identifier 523), an additional set of data elementswill be present in frame header 521, specifically a mouse X position526, a mouse Y position 527, and a mouse visible flag 528. Again, insome embodiments additional data elements may be present withoutdeparting from the scope of the invention.

Following frame header 521, each frame comprises a series of tiles 530.Each tile 530 comprises contextual data and graphics data thatcorrespond to a two-dimensional rectangle, or tile, of agent monitor240. Each frame 520 can be represented by a series of equally sizedtiles 530, for example where monitor's visible region (which isuniversally rectangular in shape) is divided in 12 tiles, in three rowsof fours tiles each. In other cases, not all tiles 530 are the samesize. For example, it may be desirable to have tiles of different sizesand of different graphics quality, each used for different regions ofmonitor 240. For instance, if a certain region on monitor 240 comprisedtext at the moment when a screen capture was taken, and the rest of thereal estate on monitor 240 was essentially featureless, then it wouldmake sense to have one or two high-quality tiles 530 that fully overlaythe area comprised of text, and then to have a series of low qualitytiles 530 to capture the surrounding featureless terrain. Anotherapproach would be to have a single low-resolution tile spanning theentire monitor 240, and then overlay a high-resolution tile 530corresponding to the area comprised of text. Similarly, areas where ahigh rate of change in graphical content is observed could be covered bytiles 530 of higher video quality, whereas regions where little changeis observed could be covered by larger tiles 530 with low graphicsquality. It should be clear to one having ordinary skill the art ofgraphical compression that there may be several alternative approachesto consider when implementing a tiling process, depending on the natureof the underlying graphical content to be captured, and any of thoseapproaches may be used to determine tiling within a frame according tothe invention.

In many situations, it will be desirable to limit the instantaneousbandwidth being used by screen capture graphics transmission. Forexample, if a VOIP telephone is being used by an agent, it will likelybe necessary to limit bandwidth use for screen capture videotransmission during a call, in order to avoid call audio qualitydegradation. Accordingly, FIG. 6 illustrates an exemplary process,according to the invention, for managing bandwidth during screen captureoperations. In a first step 600, an optional upload bandwidth limit isset. In some situations no bandwidth limits are required, for examplewhen an agent has an excellent data connection and uses a conventionalphone. Where bandwidth is required to be limited, however, a fixedbandwidth limit may be set in step 600, or a functional bandwidth limitmay alternatively be set. A functional bandwidth limit would be, forexample, a limitation that stated that packet jitter for voice signalscannot be allowed to exceed some predetermined level. In such a case,packet jitter would be measured periodically and, as it approached thespecified limit, bandwidth for other uses (including of course screencapture video transmission) would be throttled. In step 601, adetermination may be made to maintain fixed frame rate or to vary framerate for upload purposes. Since bandwidth used will always be determinedat least by frame rate and the size of data payload of a frame, allowingupload frame rate to vary will allow bandwidth to be varied. A possibledisadvantage of adopting a variable frame rate approach is that, ifupload frame rate is kept low for a long period, a significant backlogof frames waiting to be uploaded may accumulate on workstation 200, withthe result that either significant resources must be allocated onworkstation 200 to buffering video frames, or that upload operationswill be required for a significant period after a call completes (toallow buffered frames to “catch up”), which could limit flexibility inoperation of agent workstation 200 (for instance, if an agent wanted torestart workstation 200, it might be necessary to delay restart to allowtime for uploading to complete). An alternative to using variable framerates to control bandwidth is to use variable jpeg quality, since lowerjpeg (graphics) quality requires less data (and therefore lessbandwidth). Accordingly, in step 602 an acceptable overall jpeg qualitysetting is determined (lower values means less bandwidth, and viceversa). Of course, if lower overall graphics quality is needed,according to the invention it may still be desirable to maintain highgraphics quality for certain screen regions and to dramatically lowergraphical quality for others, based on characteristics of those regions.If this approach is used to get better overall results, in step 603local jpeg quality settings are determined for different screen regions.Another clear way to conserve bandwidth (or conversely to use availablebandwidth fully) is to vary video frame rate. Simply, reducing framerate by half immediately reduces bandwidth required by half, soadjusting frame rate in step 604 can be a very effective bandwidthmanagement tool. Of course, the lower frame rate goes, the lower thequality of video will be that is available to be viewed by qualitymonitors, with resulting potential loss of ability to detect and correctquality problems (which is, after all, a main purpose of capturingscreen video!). Once a group of settings has been selected in steps601-604, in step 605 screen capture and video upload operations beginusing those settings. Periodically, in step 606, it may be desirable tocheck whether new bandwidth limits have been received from screencapture server 140 or from the agent (who is, in some embodiments,provided with a “call quality” button, for example, that when pushedinitiates a series of steps to improve call quality, including possiblylimiting bandwidth available for video uploads). If changes areindicated, then the process begins again at step 600; if not, videocapture operations continue with current settings and the process movesback to step 606 until the next time it is desired to check settings.

In some embodiments a buffer is maintained in memory (typically RAM 231,although HDD 230 or other memory types could also be used) for storingframes that have been captured but not yet transmitted to media uploadserver 141. Buffers will typically be used when bandwidth is throttledin step 601 and screen capture operations generate more screen graphicsdata per unit time than can be transmitted within a given bandwidthlimit. In some embodiments a buffer of fixed size will be maintained inmemory 231, while in other cases a buffer will grow and shrink asneeded, although it may still be limited to some maximum size. In somecases, buffered data will be written to hard drive 230 when a bufferexceeds some size, or when uploading operations have been terminated(which can occur when connection to MUS 141 is lost, or when agentworkstation 200 is shut down by an agent), so that, when screen captureoperations resume at a later time, previously buffered data can beretrieved and sent to MUS 141. Note that in some embodiments buffereddata will often be “tagged” with an identity or connection informationof a particular media upload server 141 so that the associated data willall be sent to the same MUS 141; if this is not done, it will benecessary in some cases to reassemble capture screen video recordingsfrom data chunks stored on a plurality of media upload servers 141.

Since it will rarely be possible to provide unlimited bandwidth forscreen capture video uploads, it will often be the case that, when acustomer call is completed at agent workstation 200, screen capturevideo upload operations are still ongoing. Similarly, when an agent logsout, there may still be some amount of video to be uploaded, and itgenerally would be desirable to complete such uploads before allowing anagent to shut down their machine for example. And, it is often just asimportant that screen capture operations themselves (that is, capturingof screen shots into screen capture videos, rather than uploadingoperations) should be affirmatively stopped once an agent logs out orends a call, particularly if agent workstation 200 is actually owned bythe agent (as is common in the case of home agents), since it willrarely be desirable for a company to capture screen activity notassociated with its particular work requirements (such potentiallyunauthorized screen captures could represent a legal risk for thecompany). Accordingly, FIG. 7 illustrates an exemplary process,according to an embodiment of the invention, providing various methodsof terminating screen capture operations.

According to the embodiment, several conditions can trigger the screencapture shutdown process illustrated in FIG. 7. In step 700, whichtypically represents a typical shutdown mechanism, CTI server 121 sendsan event notification to SCS 140 when a call on ACD 120 is completed; instep 701 a heartbeat failure is detected at SCS 140; and in step 702 anagent logout signal is sent to SCS 140 by a web application 152 used byagents for interaction during interaction with customers. Each of thesethree signals indicate a condition in which cessation of screencapturing may be required. In the case of call completion (step 700),rules governing screen captures at a site or agent level typicallyrequire that screen capture be conducted only during customer calls orother customer interactions, although in some embodiments it isdesirable to capture all activity on agent workstation 200, regardlessof whether it is related to a customer interaction. When the firstcondition applies, each time a customer interaction is completed, SCS140 sends a “stop” signal in step 710 to SCCA. Similarly, in some caseswhen a heartbeat failure is detected at SCS 140 it may be desirable tosend a stop signal in step 710. This will also not always be the case,however, since in some cases SCCA 211 is connected to more than one SCS(for example, to backup SCS 250), and failure of a heartbeat signal at afirst SCS 140 does not necessarily mean failure of heartbeat at a backupSCS 250 (heartbeat signals are well known in the art, and are typicallytrivial datagrams sent at a predetermined periodicity from one softwareapplication to another, and then replied to by the second softwareapplication; when the second application receives a heartbeat signal, itknows the first application is still running and connected, and when itsreply is received the first application knows the second one is stillrunning and connected). In most embodiments, when an agent logs out atworkstation 200, and a corresponding signal is sent to SCS 140, SCS willsend a stop signal 710 to SCCA, particularly since it is usually notdesirable (being typically inefficient and in some cases illegal orimproper) to continue capturing screen data when no agent is logged inat workstation 200.

Once SCS 140 sends a stop signal to SCCA 211 in step 710, SCCA 211 inturn sends a stop signal to screen capture module 220 in step 711. Thissecond stop signal in a chain may also be triggered directly if SCCA 211in step 712 detects heartbeat failure (this occurs when SCCA 211 detectsloss of heartbeat with SCS 140; note that in many cases when in step 701SCS 140 detects loss of heartbeat with SCCA 211, its stop signal may notbe received by SCCA 211, particularly if there is a loss of networkconnectivity between SCS 140 and SCCA 211).

When screen capture module 220 receives a stop signal from SCCS 211, itstops capturing screen graphics data in step 720. This action may alsobe triggered by detection, in step 721, of the fact that the agent'sbrowser 210 has been closed (this is usually desirable since, whenbrowser 210 closes, applet 211 is automatically terminated as well, andtherefore all control signals to screen capture module are lost).Detection of browser closure may be detected in various ways known inthe art. For example, it is often possible to configure operating system235 to throw events when a particular application terminates, usingscripting tools generally provided with operating system 235. In anotherembodiment, screen capture module 220 may periodically query operatingsystem 235 to check the running state of browser 210, and when thatstate is found to have changed from “running” to “not there”, screencapture module 220 can conclude that browser 210 must have stoppedrecently. When screen capture module 220 stops screen captureoperations, it does not necessarily stop all activities. Generally, itwill be desirable to complete processing of any already-captured datastored in a buffer in memory 231 or on disk 230 before closing screencapture module altogether, and accordingly this is done in step 730. Instep 731, if upload is not possible (for instance, if connection tomedia upload server 141 has been lost), remaining chunks are typicallyarchived locally on HDD 230 until a subsequent upload opportunity.Finally, after all data has been uploaded or archived, screen capturemodule 220 may optionally be stopped and, also optionally, uninstalledand removed from workstation 220. In some embodiments, screen capturemodule 220 is installed permanently when first uploaded, for instance asa Windows service, and run each time workstation 200 starts up. In theseembodiments, screen capture module 220 is always “at the ready”, andneed not be uploaded, installed, or started in future screen captureoperations. In other embodiments, it may be desirable to completelyremove screen capture module 220 after each agent login session, so thatscreen capture module 220 is only present on workstation 200 when it isoperating under the control of SCCA 211, which itself is dependent onbrowser 210 (which contains it) and under the control of SCS 140.

In some cases it will be desirable not only to capture screen data forrecording and storage in media storage database 142 but also forsupporting real-time monitoring of agent interactions with customers.For example, and referring to FIG. 8, in an embodiment a supervisor atsupervisor monitoring station 860 may elect to monitor an ongoing callor other interaction between an agent and a customer. Typically ACD 120provides a capability for a supervisor to silently monitor a call usingphone 861 (which is usually connected directly to ACD 120, but need notbe; it could be connected via a network-resident switch 801 located inPSTN 161). Supervisor monitoring workstation is connected via Internetor intranet (or other corporate data network) 160 to web server 150,which provides application via web application server 151 to webapplications 152, including particularly a supervisor version of anagent's web application (it is common in the art for supervisors andagents to use web-based applications to do all of their work, and forthe two applications to be essentially the same, but with differentfeatures activated according to the varying needs of different users anduser types). In typical embodiments, supervisor workstation 860 will beconfigured similarly to agent workstation 200 (although it may notinclude its own screen capture control application 211 and screencapture module 220—but in some cases it will), and specifically willhave a browser 210 which can be used to access web application 152. Atypical supervisor or quality monitor web application will provideinformation about agent performance, calls in queue, and so forth, andmay include a tab or other user interface element to allow a supervisorto enter a “monitoring mode”. When monitoring an agent's interactionwith a customer, a supervisor will generally listen to the audio viatelephone 861 (most ACDs, again, support this functionality natively),and will be able to view video of what is happening on the agent'sworkstation by either downloading screen videos from media upload server141, which of course would have some amount of latency as video won't beavailable until it has been uploaded from agent workstation 200;alternatively, and particularly when use of a dedicated corporatenetwork 160 means that bandwidth is plentiful, video may be streameddirectly from screen capture module 220 on agent workstation 200 tosupervisor workstation 860 for real-time viewing.

In large enterprises, and when robust screen capture capability isdesired, it is often desirable to use more than one of eachnetwork-based component to provide better scalability and faulttolerance. Accordingly, in a preferred embodiment illustrated in FIG. 9,screen capture module 220 may interact with an upload load balancer ofan upload proxy server 920, instead of with a media upload server 141directly. Similarly, screen capture control applet 211 may connectdirectly to a screen capture server load balancer or SCS proxy server910 instead of directly to a screen capture server 140. When screencapture module 220 connects to proxy server 920, it behaves identicallyto how it behaves in embodiments where it is connected directly to mediaupload server 141, which of course is one of the primary functions of aproxy server: clients of a proxy server should generally not have to bemodified to work with the proxy server. Accordingly, in some embodimentsscreen capture module 220 maintains a heartbeat mechanism with proxyserver 920, and uploads screen graphics video directly to proxy server920. Proxy server 920 then allocates load among a plurality of mediaupload servers comprising media upload server 1 921 through media uploadserver n 922. Generally each customer interaction will be allocated to aspecific media upload server 921, 922 by proxy server 920, so thatcustomer interaction data can be stored in one place, although in someembodiments packets of data comprising records 501 or even independentframes 520 are sent by proxy server to any media upload server 921, 922.In such embodiments where customer interactions are uploaded usingmultiple upload servers 921, 922, in some cases data is reassembled bycustomer interaction by using an indexing scheme or by allocatingdifferent local storage facilities such as local storage 1 931 and localstorage n 932. In some embodiments a single master storage 930 ismaintained, receiving every packet from every media upload server 921,922 and carrying out additional functionality to, for instance,eliminate duplicate packets and to order packets and potentially tostore them by customer interaction. Similarly, when screen capturecontrol applet 211 connected directly to a proxy server 910 instead ofSCS 140, it behaves as if it were connected to SCS 140 including forexample maintaining a heartbeat signal, notifying proxy server 910 ofchanges on agent workstation 200, and receiving control signals fromproxy server 910. As is common to proxy servers in general, SCS proxyserver 910 does not carry out actual screen capture controlfunctionality, but rather passes notifications and requests between SCCA211 and one or more screen capture control servers, such as screencapture control server 1 911 and screen capture control server n 912. Insome instances, a master screen capture control server 913 may be used,for instance where a single point of communication with a CTI server 121or an interaction server 125 is desired. Moreover, in some embodimentsmultiple SCS masters 913 may be employed, each acting as master for aparticular set of CTI servers 121 and interaction servers 125; in otherembodiments each SCS 911-913 may act both as a master and as a slave,acting as master for certain CTI servers 121 and interaction servers125, and acting as a slave for all of the rest. In this type ofarrangement, when a signal from an SCCA 211 is passed to SCS proxyserver 910 and thence on to SCS server n (based on load balancing), andwhen the signal pertains to a CTI server 121 for which SCS server 1 911is the master, SCS server n would pass the message to SCS 1 911 forongoing transmission to the appropriate CTI server 121.

In some embodiments Upload Load Balancer 920 receives requests fromscreen capture application 220 and, for each request, delivers back anaddress to screen capture module 220 that corresponds to one of aplurality of media upload servers 921, 922, and screen capture module220 then connects directly with the designated media upload server 921,922 to upload screen capture data. In this configuration, server 920acts merely as a load balancer for a plurality of media upload servers.

The skilled person will be aware of a range of possible modifications ofthe various embodiments described above. Accordingly, the presentinvention is defined by the claims and their equivalents.

What is claimed is:
 1. A system for zero-footprint screen capture,comprising: a screen capture server comprising a plurality of softwareprogramming instructions stored in a memory and operating on a processorof a computing device; a screen capture software application comprisinga plurality of software programming instructions configured to beuploaded to a client device via a network; a web server comprising aplurality of software programming instructions stored in a memory andoperating on a processor of a computing device, and configured toreceive interaction from a client device via a network; wherein the webserver is further configured to upload the screen capture softwareapplication to the client device from which the interaction wasreceived; and wherein the screen capture server is directed by the webserver to control the operation of the uploaded screen capture softwareapplication, and to receive screen capture data from the uploaded screencapture software application.
 2. The system of claim 1, wherein thescreen capture data comprises image data based at least in part on animage being shown on a connected display hardware device operating onthe client device.
 3. The system of claim 1, wherein the screen capturedata is stored for future reference.
 4. The system of claim 1, whereinthe screen capture data is presented to a human user for review via adisplay hardware device operating on a computing device configured tocommunicate with the screen capture server.
 5. The system of claim 1,wherein the screen capture software application is further configured tocompress the screen capture data prior to transmission, and the screencapture server is further configured to decompress the screen capturedata upon receipt.
 6. The system of claim 1, wherein the screen capturedata further comprises location data based at least in part on thephysical location of the client device.
 7. The system of claim 6,wherein the location data is based at least in part on a network addressof the client device.
 8. The system of claim 1, wherein a portion of thescreen capture data is modified by the screen capture softwareapplication prior to transmission.
 9. The system of claim 8, wherein themodification comprises the obfuscation of data.
 10. The system of claim8, wherein the modification comprises the removal of data.
 11. A methodfor zero-footprint screen capture, the method comprising the steps of:receiving, at a web server comprising a plurality of softwareprogramming instructions stored in a memory and operating on a processorof a computing device, an interaction from a client device via anetwork; uploading to the client device a screen capture softwareapplication comprising a plurality of software programming instructionsconfigured to receive a plurality of screen capture data from the clientdevice and to transmit at least the screen capture data to a screencapture server comprising a plurality of software programminginstructions stored in a memory and operating on a processor of acomputing device; directing, via the screen capture server, the screencapture software application to capture and transmit screen capturedata; receiving and storing screen capture data from the screen capturesoftware application at the screen capture server.